home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-vaudreuil-mime-delivery-00.txt
< prev
next >
Wrap
Text File
|
1993-09-21
|
14KB
|
343 lines
Network Working Group Greg Vaudreuil
Internet Draft Tigon
Expires 3/17/93 September 17, 1993
Delivery Report Content-Type for use with MIME
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents of
the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents as
Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is inappropriate
to use Internet Drafts as reference material or to cite them other than as a
"work in progress".
2. Abstract
The memo defines a MIME content type for the return of delivery reports,
service availability, and receipt notifications. This content type is
intended to be machine processable while remaining human readable.
3. Introduction
The current Internet Mail protocol suite is lacking in several features
necessary to the management of large mailing lists and for error processing
on behalf of a user. There is no standard error report format which would
facilitate implementation of user friendly mail interfaces. This content
type defines a mechanism for delivery reports which is extensible for a range
of system to user notification services such as read receipt delivery,
positive delivery acknowledgment, and service non-availability notification.
3.1. Non-Delivery Notification
The Internet currently provides for error reports, but in a non-standard and
limited use format. This specification is intended to replace these error
reports with a more standard mechanism. SMTP provides a standardized status
reporting system in the use of numeric reply-codes but these are not
generally made available in the error message mailed to the sender. The SMTP
error codes do not provide a complete diagnostic record and need to be
extended for the purposes of delivery reports to include non-SMTP network and
communications errors which may cause non-delivery.
3.2. Positive Delivery Notification
The RFC822/MHS mapping standards identify a mechanism for requesting such a
delivery notification and this specification provides a mechanism to return
such a request. For the purposes of the Delivery Notification, delivery will
be considered completed when the message is delivered to the destination
mailbox.
3.3 Read Receipt Notification
There is a mechanism specified in the RFC822/MHS documents for requesting a
read receipt notification. While the specific implementation of such a
notification has been contentious, this specification provides a mechanism
for sending such a notification if one is to be implemented. The specific
meaning of "read" varies by implementation environment and is left undefined.
3.4 Service Notification
MIME allows the sending of mixed-media messages and in particular messages
which are not text. There is no specific mechanism for reporting to the
sender when such a message is deliverable but not readable. In many
messaging environments, it may be useful to return a message to the sender
indicating that the specified content-type is unsupported. It is expected
that this information will be cached, either informally by a human user, or
by a local directory for use by the user agent. Determination of what is a
supported and what is an unsupported feature is an implementation issue
4. Delivery Report Framework
The delivery report mechanism is implemented by defining two new MIME
content-types, Multipart/Delivery-Report and Application/Delivery-Report.
The multipart/delivery report is the syntactically the same as a
multipart/mixed but contains exactly two parts, the first is the
Application/Delivery-Report and the second is a return of content. If return
of content is not requested or supported, the Multipart/Delivery Report is
not needed.
The Application/Delivery-Report contains the specific delivery information,
such as error reports, read-receipts, and service notifications. This
content-type is formatted according to the Simple Text Interchange Format and
contains information for machine processing of the message. STIF Comments
are permitted where appropriate for human consumption in the absence of an
application capable of interpreting the error report.
5. Multipart/Delivery-Report
Mime type name: Multipart
Mime Sub-Type name: Delivery-Report
Required Parameters: Boundary
Optional Parameters: None
Encoding Considerations: Quoted-Printable and Base-64 are prohibited.
The syntax of a Multipart/Delivery-Report is identical to the Multipart\Mixed
content type. The Delivery Report always contains two body parts. The first
body part is an Application/Delivery-Report, defined in a subsequent section
of this appendix. The second body part may be of any content-type and
contains the returned message for which the delivery report is defined. The
returned comment will normally be a message/RFC822.
If an Application/Delivery-Report does not include returned content,
Multipart/Delivery-Report should not be used.
6. Application/Delivery-Report
Mime type name: Application
Mime Sub-Type name: Delivery-Report
Required Parameters: None
Optional Parameters: None
Encoding Considerations: 7bit is always sufficient.
The Application/Delivery-Report body is designed to deliver delivery and
non-delivery reports, read-receipts, and service notifications. It is
generally used with a Multipart/Delivery-Report when the original content is
to be returned to the sender.
The Application/Delivery Report is a series of attribute-value pairs
formatted as RFC 822 headers. While this body-part is designed to be machine
parsable, US-ASCII comments are permitted in each line.
Generation of error messages from this error report for user consumption
should be based on the error code, not the explanatory text. Choice of an
appropriate language and character set is independent of the error. The
choice of US ASCII for the explanatory text is based on current practice and
is expected to be obsoleted by nationalized user interfaces.
6.1. Required Attributes.
o Message-ID: - message id of the message being reported on
o Intended-Recipient - a coma separated list of one or more recipient
email addresses for which this report applies.
o Delivery-Status - This field indicates whether further delivery attempts
will be made. (Finished, Continuing)
6.2 Service Specific Attributes
o Message-Delivered - Time of message delivery
o Message-Not-Delivered - Time of failed attempt
o MTA-Error-Code - Error code returned which caused delivery notification
to be returned. The set of error codes defined by the SMTP protocol is
extended to address general network errors.
o Service-Not-Available - MIME content type of service not supported on
the destination mailbox.
o Message-Read - Time message was read
6.2. MTA Error Codes
The following non-delivery error codes are available from SNMP for direct
peer-to-peer networking.
The 400 series of error codes are "soft" failures, indicating that re-try is
reasonable at a later time.
421 <domain> Service not available, [This may be a reply to any command if
the service knows it must shut down]
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox
busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
The 500 series of error codes are "hard" failures, indicating that the
message should be returned to the sender as undeliverable. The listed
commands are a subset of the full SNMP diagnostics.
500 Syntax error, command unrecognized This may include errors such as
command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable, mailbox not found, no
access
551 User not local; please try <forward-path>
552 requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed [E.g., mailbox
syntax incorrect]
554 Transaction Failed
6.3. Network Error Codes
Often mail transfer failures result from network or transport level
conditions which are not part of the SMTP protocol. These errors are
generally made known in current error reports, but need to be assigned
numeric codes to be used in the Application/Delivery-Report content type. A
new series of error codes, 6XX is created to report on such failures.
600 Host unreachable. The network address of the host specified is not
connected to the MTA.
610 Network Unreachable. The network the host resides upon is either not
connected to the MTA.
620 Hostname does not exist. A non existent destination was provided.
630 Service not available. SMTP on TCP port 25 is not available.
7. Return of Content
Return of content may be wasteful of network bandwidth and a variety of
implementation strategies can be used. Generally the sender should choose
the appropriate strategy and inform the recipient of the required level of
returned content required. This can be done with the RFC822/MHS header
"return content". The three values for this field are "none", "full", and
"initial". The default behavior in the absence of this header varies by
application and should be set by the MTA.
Return of full content uses significant bandwidth but enables review and
resending with a different addresses or formats.
Return of content can be provided with caching without using additional
network bandwidth. Outgoing messages can be cached for a suitable period of
time, and if a non-delivery, service notification, or read-receipt is
received, it can be matched with the cached message and presented to the
user.
Return of a partial message segment may be sent to remind the sender of the
topic of the message. This saves bandwidth compared with sending the full
message, but may either not be enough of the message for context or be
unsuitable for further processing. Handling of partial content is tricky in
a mixed media environment. Return of partial content may be useless for
certain content-types. Each content-type has a natural "unit" which should
be respected in returning a partial content. For example, a text message
should include enough text to capture at least the first paragraph. A fax
content should include sufficient information to print the cover page. A
audio segment should contain enough data for several seconds of play time.
Each of these units varies in the number of bytes and cannot be implemented
in a useful manner by arbitrary truncation.
It is recommended that a gateway return full or no content. It should return
partial content only if it has knowledge of how to truncate that content.
The following are recommended units for truncation.
Multipart/* Return first body part
Image/* Return one page
Audio/* Return 10 seconds
Text/* Return 1 page
8. Example Delivery Reports
8.1. Complete Non-Delivery Notification
The following error message was sent to the user 2145551212 on message
machine HOST1.mycompany.com because the message addressed to 2145551234 does
not exist on message machine HOST2.mycompany.com. The error message was sent
by the mail program itself and not on behalf of a particular user and
therefor has the From: address of "Postmaster". Note that this is not
relevant to the user.
To: 2145551212@host1.mycompany.com
From: postmaster@host2.mycompany.com
Mime-Version: 1.0
Date: Mon, 3 Fri 93 13:39:31 PDT
Message-ID: HOST2.mycompany.com-1212121212
Content-type: Multipart/Delivery-Report; boundary =
"error-report-boundary"
--error-report-boundary
content-type: Application/Delivery-Report
Message-Id: host1.mycompany.com-123456789
Intended-recipient: 2145551234@host2.mycompany.com
Delivery-Status: Finished
Message-Not-Delivered: Fri, 3 Sep 93 13:39:31 PDT
MTA-Error-Code: 550 (Invalid mailbox)
--error-report-boundary
Content-type: Audio/U-Law
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
dflksdlkfIasdrkfpWlqkw3okWlkgf9i345kWlfkg9iugp34k5poi09fg
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
krQgi35oktWldkfbrpouqe5yklm2poTihcvxbQkmstyTi5ryToifnglkj
dlkgpokpeowrit09IpokporkgwI==
--error-report-boundary--
8.2. Example Read Receipt Message
The following delivery report was sent to user 2145551212 on machine
host1.mycompany.com after the message sent to 2145551234 on machine
HOST2.mycompany.com was read. No return of content was requested.
To: 2145551212@host1.mycompany.com
From: 2145551234@host2.mycompany.com
Message-ID: HOST2.mycompany.com-1212121212
Mime-Version: 1.0
Date: Mon, 3 Fri 93 13:39:31 PDT
Content-type: Application/Delivery-Report
Message-Id: host1.mycompany.com-123456789
Intended-recipient: 2145551234@host2.mycompany.com
Delivery-Status: Finished
Message-Read: Fri, 3 Sep 93 13:39:31 PDT
9. Security Considerations
Delivery notifications are only as secure as the mechanism by which they have
been sent. It is important to note that automatic deletion of an address
from a mailing list based on delivery reports may provide a mechanism for
denial-of-service attacks.
10. Authors Address
Gregory M. Vaudreuil
Tigon Corporation
17060 Dallas Parkway
Suite 109
Dallas, Texas 75248-1905
(214) 733 2722
GregV@cnri.reston.va.us